System and method for generating dynamic repayment terms

ABSTRACT

In one embodiment, a method includes receiving, by a payment service system, a payment request to charge a payment card for a transaction. The payment card is associated with a user account maintained by the payment service system and the user account is configured to apply a different interest rate to each of multiple transactions. The method includes in response to receiving the payment request, identifying, by the payment service system, purchase characteristics of the transaction. The method includes determining, by the payment service system, an interest rate to be associated with the payment request based on the identified purchase characteristics and historical repayment data stored in a data store of the payment service system. The method includes upon receiving a payment confirmation from the user, updating, by the payment service system, the user account to include the transaction at the determined interest rate.

PRIORITY

This application claims the benefit under 35 U.S.C. § 119(e) of U.S.Provisional Patent Application No. 62/929,104, filed 1 Nov. 2019, whichis incorporated herein by reference.

BACKGROUND

A line of credit is a credit facility extended by a bank or otherfinancial institution to a government, business, or individual customerthat enables the customer to draw on the facility when the customerneeds funds. A line of credit takes several forms, such as an overdraftlimit, demand loan, special purpose, export packing credit, term loan,discounting, purchase of commercial bills, etc. It is effectively asource of funds that can readily be tapped at the borrower's discretion.Interest is paid only on money actually withdrawn. Lines of credit canbe secured by collateral or may be unsecured.

A credit card is a payment card issued to users (cardholders) to enablethe cardholder to pay a merchant for goods and services based on thecardholder's promise to the card issuer to pay them for the amounts plusthe other agreed charges. The card issuer (usually a bank) creates arevolving account and grants a line of credit to the cardholder, fromwhich the cardholder can borrow money for payment to a merchant or as acash advance. A credit card allows the consumers to build a continuingbalance of debt, subject to interest being charged.

An installment loan is a loan that is repaid over time with a set numberof scheduled payments; normally at least two payments are made towardsthe loan. The term of loan may be as little as a few months and as longas 30 years. For example, a mortgage is a type of installment loan.

BRIEF DESCRIPTION OF THE DRAWINGS

Non-limiting embodiments of the present disclosure are described by wayof example with reference to the accompanying figures which areschematic and are not intended to be drawn to scale. Unless indicated asrepresenting the background art, the figures represent aspects of thedisclosure.

FIGS. 1A and 1B illustrate an example payment service system networkaccording to one embodiment.

FIG. 2 illustrates an example system architecture for a payment servicesystem according to one embodiment.

FIGS. 3A-3B illustrates a process for generating repayment terms for atransaction in accordance with an example embodiment.

FIGS. 4A-4B illustrates a process for generating repayment terms for atransaction using a payment card in accordance with an exampleembodiment.

FIGS. 5A-5B illustrates a process for generating repayment terms foraccessing a line of credit in accordance with an example embodiment.

FIGS. 6A-6C illustrates a process for generating repayment terms forborrowing from another user in accordance with an example embodiment.

FIGS. 7A-7C illustrate example use interface associated with accessing adebt instrument according to one embodiment.

FIGS. 8A-8E illustrate example user interfaces associated with accessinga debt instrument according to one embodiment.

FIGS. 9A-9F illustrate example user interfaces associated with accessinga debt instrument according to one embodiment.

FIGS. 10A-10C illustrate example user interfaces associated withaccessing a debt instrument according to one embodiment.

DESCRIPTION OF EXAMPLE EMBODIMENTS

Particular embodiments described herein enable management andimplementation of debt instruments, such as traditional line, credit andcredit card account, or installment loan through a payment servicesystem. Particular embodiments described herein enable a user to accessa debt instrument to make a payment for a transaction, request a cashtransfer, or request to borrow funds from another consumer. Particularembodiments described herein enable analysis of purchase characteristicsof a transaction in order to determine suitable repayment terms for thetransaction. Particular embodiments allow for dynamic repayment termsincluding modification of default repayment terms in real-time based onthe characteristics of the transaction. Particular embodiments improve auser's access to a line of credit that improves user repayment through adetermination of a repayment schedule that fits the user.

Particular embodiments enable training a machine learning model toclassify levels of risk of indebtedness for different user profiles ortransaction profile contexts and determine repayment schedules thatminimize the level of risk. As an example and not by way of limitation,the machine learning model may be trained to identify high-risk userprofiles or transaction profile contexts based on analyzing transactionhistories of users. That is, if a user typically spends the majority oftheir balance on their account, that may lead to an inability to payback debt. As such, the machine learning model may determine a repaymentschedule that reduces the level of risk associated with that particularuser of failing to pay back debt. For instance, the machine learningmodel may determine an optimal repayment schedule would be to spreadpayments over multiple weeks to enable the user to pay off small amountsof debt at a time. As another example and not by way of limitation, thetransaction profile contexts may indicate a context of a transaction andthe machine learning model may identify certain transactions (e.g.,luxury goods, items of a threshold amount, purchase made in a certainarea) that may be a high-risk transaction. The machine learning modelmay determine a repayment schedule that mitigates the risk of the userfailing to pay back debt. The machine learning model may be trained toidentify trends associated with high-risk user profiles and/ortransaction profile contexts. The machine learning model may be trainedto determine a corresponding repayment schedule in order to minimizelevel of risk of a user failing to pay back debt.

Currently, most purchases using a debt instrument (e.g., a credit card,a line of credit, or an installment loan) come with fixed terms (e.g., aset repayment schedule, an interest rate, a payment due date, and thelike). However, some transactions may be determined to be a high-risktransaction than other transactions whereas some transactions may be alow-risk transaction. Additionally, it may solely be the institutionsissuing the debt instruments that may change the terms for the debtinstrument.

In particular embodiments, a payment service system may provide aplatform for its users to access one or more debt instruments that maybe associated with their respective accounts. These debt instruments mayinclude a credit card that is may be issued by the payment servicesystem or an entity associated with the payment service system. Thesedebt instruments may also include a line of credit that is associatedwith a user's account. In particular embodiments, the payment servicesystem may manage one or more financial accounts for the user. Thesefinancial accounts may include one or more debt instruments that areavailable to the user. Each financial account may hold an actual orrepresentative quantity of fiat currency owned by the user or otherassets owned or assigned to the user (e.g., securities, cryptocurrencytokens). The payment service system may also have access to one or morefinancial accounts associated with the user that are managed by one ormore third-party systems (e.g., banks).

In particular embodiments, the payment service system may maintain adatabase designed for recording asset ownership for various users. As anexample and not by way of limitation, the payment service system maystore one or more ledgers for tracking assets and liabilities held bythe payment service system—each such asset or liability being held bythe payment service system may be owned in whole or in part by thepayment service system itself and/or in whole or in part by one or moreusers of the payment service system. The ledger(s) may store servicebalances associated with the payment service system representingquantities of assets or liabilities held by the payment service system.The service balances may comprise, for example, a fiat currency balancefor each of one or more fiat currencies, a securities balance for eachof one or more security assets, a cryptocurrency balance for each of oneor more cryptocurrencies, a liabilities balance for each of one or moredebt instruments, other suitable data records, or any combinationthereof. The payment service system may also store additional ledgersfor each of a number of users. The ledger(s) may be stored as part of aprofile for each user. One or more ledgers may store user balancesrepresenting quantities of assets held by the payment service system andowned by one or more users. They may have similar contents to theservice balances. One or more ledgers may be debt ledgers that tracktransactions associated with debt instruments of the user. The paymentservice system may use other data structures suitable for storinginformation representing ownership of assets.

In particular embodiments, a user may access a debt instrumentassociated with his or her account through the payment service system bysending a request to access a debt instrument to the payment servicesystem. The user may be conducting a transaction, such as making apurchase at a store via a point-of-sale (POS) device, making an onlinepurchase, sending money via a peer-to-peer (P2P) transaction, requestinga cash advance form a line of credit, or the like. In particularembodiments, a request to access a debt instrument may be automaticallysent when the user is using a debt instrument (e.g., a credit card) tomake a payment for a transaction. As an example and not by way oflimitation, a user may swipe a payment card associated with the user'saccount and the request may be automatically generated and sent to thepayment service system. In particular embodiments, the user may access auser interface to request access to a debt instrument. As an example andnot by way of limitation, a user may interact with a mobile applicationassociated with a payment service system or other entity to access auser interface associated with a line of credit or on a webpagedisplayed by a browser installed on a computing device. The user mayinteract with one or more elements in a user interface to select to pull(e.g., cash advance) from the line of credit by requesting to transfer aportion of the line of credit to the user's balance. As an example andnot by way of limitation, if a user has a balance of $400 on a financialaccount and wishes to maintain a balance of $300 (e.g., possibly forrent) the user may want to access a line of credit for any purchasegreater than $100 to prevent the balance from falling below that amount.As such, the user may pull from a line of credit associated with thefinancial account (e.g., a line of credit of $200) to transfer a portionof the line of credit for a transaction. The user may input, through oneor more elements of a user interface, a value to pull from the line ofcredit and send a request to the payment service system to transfer theportion of the line of credit to the user's balance.

In particular embodiments, the user may set a balance threshold toprevent the user balance from falling below a threshold amount. As anexample and not by way of limitation, a user may set a $300 limit for abalance of a financial account so if any transaction should lower thebalance to below the $300 limit, a request may be generated to request atransfer of a portion of a line of credit associated with the financialaccount to the user's balance. In particular embodiments, the balancethreshold may be assigned to a specific transaction (e.g., rent) andthat may cause the balance to fall below the balance threshold. As anexample and not by way of limitation, the balance threshold may be setfor purchases that are not associated with rent or utilities. Inparticular embodiments, the payment service system may receive therequest to pull a portion from the line of credit, and automaticallysend a request to a computing device associated with the financialaccount (e.g., a smartphone the user has signed into the financialaccount) for authorization for the pull from the line of credit. Therequest may be automatically generated for an amount for a transaction.As an example and not by way of limitation, if a user has a limit setfor $300, has a balance of $400, and is looking to purchase groceriesfor $125, a request to pull $25 from a line of credit associated withthe user's financial account may be generated. The payment servicesystem may send a notification of the transaction exceeding a setbalance threshold and send a request to the user's smartphone forauthorization to approve the pull from the line of credit for $25. Inaccordance with one embodiment, and prior to sending the authorizationto the user, the payment service system may perform a real-time riskassessment of the transaction and generate modified repayment terms forthe $25 pull from the line of credit. The modified repayment terms candiffer from the default repayment terms associated with the debtinstrument (e.g., line of credit) of the user account and are based onthe characteristics of the transaction. For example, the payment servicesystem may analyze the characteristics of the request/transaction todetermine that it relates to a grocery store purchase (based ongeolocation data), a confirmed pull request under $50, and is within afew days or next payroll deposit (based on past transaction history onthe payment service). These factors may cause the payment service systemto offer modified repayment terms (from default terms) with a shorterrepayment schedule and with a lower interest rate. Once the userapproves the pull from the line of credit for $25 the payment servicesystem at the identified terms, the transaction may be authorized andthe payment service system may update the user account to include thepull from the line of credit at the default or modified repayment terms.

In particular embodiments, the payment service system may identifypurchase characteristics of a transaction. The purchase characteristicsmay include merchant information (e.g., merchant identifier, a merchantinventory information, and the like), whether the transaction is aproduct or a service, a category associated with the transaction, a dateand time associated with the transaction, a merchant category code (MCC)associated with the transaction, and whether the transaction is a luxuryitem. Other purchase characteristics may be included. The paymentservice system may extract purchase characteristics from transactiondetails, request information from the merchant, and other avenues toidentify one or more purchase characteristics of a transaction. As anexample and not by way of limitation, if a user is attempting topurchase a new laptop through a payment card associated with thefinancial account, the payment service system may be able to identifyfrom the request, that the transaction is for a new laptop, from aparticular merchant, at a particular date and time, and the like. Thepayment service system may determine a category associated with thetransaction or extract it from the transaction details. The paymentservice system may identify individual items of a transaction and/orgroup items together in particular categories. As an example and not byway of limitation, if a transaction includes multiple items of differentcategories, the payment service system may identify each individualcategory. In particular embodiments, the payment service system mayextract one or more feature vectors representing the purchasecharacteristics and classify each of the feature vectors. Theclassification of each feature vector and other purchase characteristicsmay be used to determine a set of terms associated with the transactionas described herein. In particular embodiments, the payment servicesystem may also determine historical repayment data. The historicalrepayment data may be associated with the user account and/or associatedwith the transaction. As an example and not by way of limitation, thehistorical repayment data may be data on how a user pays back debt orhow a particular transaction (e.g., a particular model of a car) is paidback. The historical repayment data may be determined by analyzing priortransactions of the user account and/or of similar transactionsinvolving other users of the payment service system. The payment servicesystem may use a machine learning model to assess one or more priortransactions and/or one or more similar transactions to determine thehistorical repayment data for the transaction. In particularembodiments, the payment service system may access incoming payroll, adeposits activity, cash flow associated with equities or securities, orP2P transactions.

In particular embodiments, the payment service system may dynamicallydetermine a set of terms or repayment terms associated with atransaction that uses a debt instrument. The set of terms or repaymentterms may include a payment due date of when to pay off a transaction, arepayment schedule, and an interest rate for a transaction, or a feeassociated with the transaction. In particular embodiments, the paymentservice system may use a machine learning model applied to the incomingpayroll, the deposits activity, the cash flow associated with equitiesor securities, and/or the P2P transactions to generate repayment terms.In particular embodiments, when a user sends a request to access a debtinstrument to make a payment for a transaction (e.g., using a paymentcard or directly with a mobile application on a computing device), thepayment service system may determine a set of terms based on purchasecharacteristics associated with the transaction and historical repaymentdata. As an example and not by way of limitation, the payment servicesystem may identify through the historical repayment data that the userhas a threshold number of missed payments. The payment service systemmay increase an interest rate associated with the transaction based onthe number of missed payments. As an example and not by way oflimitation, if the user has missed two payments, the payment servicesystem may increase the interest rate for the transaction by a smallamount, but if the user has missed ten payments, the payment servicesystem may increase the interest rate by a large amount or automaticallyreject an access to a debt instrument. As another example and not by wayof limitation, the payment service system may determine a particularcategory of transactions (e.g., high-end electronics) may be a high-risktransaction, and increase the interest rate associated with atransaction of that category that uses a debt instrument. Conversely, atransaction that is identified as a low-risk transaction (e.g.,groceries with a cost that is lower than a threshold amount) may have areduced interest rate. The payment service system may determine that thetransaction includes multiple items of different categories and generatean aggregate set of terms based on the combination of the individualitems in the transaction. As an example and not by way of limitation,the payment service system may determine repayment terms associated witheach item apply weights to each of the repayment terms to determine anoverall set of terms. For instance, the interest rate may be adjusted upor down based on the various risk assessments of each item. Weights maybe applied based on a fraction of the cost of the respective itemcompared to the total cost of the transaction. In particularembodiments, the payment service system may provide an itemized receiptof a transaction. The itemized receipt may be provided to the user toselect which item to take a loan out for (e.g., pay with a credit cardor pull from a line of credit) to pay for the transaction. With theitemized receipt, individual repayment terms may be shown for eachindividual item in the transaction based on their respective purchasecharacteristics. The user may be presented with an option to combine thewhole transaction and/or select individual items of the transaction totake a loan out to pay for the respective item. As another example andnot by way of limitation, the date and time of a transaction may be usedto determine the repayment terms. For example, the payment servicesystem may determine purchases around Christmas time may be high-risktransactions and increase an interest rate for a transaction using adebt instrument during that period of time. The payment service systemmay also move up a payment due date (to encourage a user to pay backdebt before requesting to access a debt instrument) or push back thepayment due date (to allow more time for a user to pay back the debt)based on the purchase characteristics or historical repayment data. Thepayment service system may apply a fee to an amount associated with atransaction using a debt instrument. As an example and not by way oflimitation, the payment service system may apply a 2.5% fee for any pullon a line of credit. Like the other set of terms or repayment terms, thefee may change based on any of the purchase characteristics, thehistorical repayment data, or other data associated with the useraccount. In particular embodiments, a payment service system may use anidentified merchant to determine the repayment terms. As an example andnot by way of limitation, a merchant may be running a promotion throughthe payment service system and advertise a lower interest rate or lowerfee to access a debt instrument for transactions at the merchant (ortransactions for a particular service or product). The merchant mayprovide a fee to the payment service system to alter the repaymentterms. In particular embodiments, the fee may be charged instead ofinterest on the pull on the line of credit. As an example and not by wayof limitation, if the interest rate associated with the line of creditis typically 20% APR, the line of credit may have a 2.5% fee that may becharged for any pull on the line of credit instead of paying interest onthe pull on the line of credit. Therefore, if the user is requesting topull $20 from the line of credit, then the user has the option to pay$0.50 instead of having interest charged for the pull on the line ofcredit. In particular embodiments, the user may be a merchant using thepayment services of the payment service system. The payment servicesystem may use a machine learning model applied to attributes of an itemor service associated with the transaction, a current merchant inventoryof the merchant, or a recent transaction activity of the merchant togenerate the set of terms or the repayments terms. As an example and notby way of limitation, if the recent transaction activity indicates themerchant is having a slow month, the payment service system maydetermine a higher interest rate be applied to non-business relatedpurchases (e.g., purchases that are not of a particular categoryassociated with the business of the merchant). The increase in interestrate may deter the merchant from making frivolous purchases.

In particular embodiments, the payment service system may determine arepayment schedule for a transaction using a debt instrument. Thepayment service system may have a standard or default repayment schedulefor transactions using a debt instrument. The payment service system mayuse a machine learning model applied to the incoming payroll, thedeposits activity, the cash flow associated with equities or securities,and/or the P2P transactions to generate a modified repayment schedule.The payment service system may alter the standard repayment schedulebased on a generated repayment schedule. This repayment schedule may becustomized to optimize repayment of debt instruments. As an example andnot by way of limitation, the payment service system may determine thata user gets paid bimonthly and as such set up or modify a repaymentschedule that coincides with after a user gets paid (e.g., the next dayafter pay day). In particular embodiments, the payment service systemmay receive an indication the user has been paid and deduct a portion ofthe paycheck to repay debt (credit card, installment loan, etc.). Inparticular embodiments, the payment service system may use purchasecharacteristics such as when the transaction took place to determine therepayment schedule. As an example and not by way of limitation, thepayment service system may extend a repayment schedule (e.g., from 8weeks to 10 weeks) for transactions that take place during a shoppingholiday. In particular embodiments, the payment service system maydetermine the repayment schedule based on the amount associated with thetransaction. As an example and not by way of limitation, if an amountfor a transaction is large, the payment service system may extend therepayment schedule based on historical repayment activity associatedwith similar transactions on the platform. This may help encouragepayback of the debt before accruing any interest. The large transactionmay also have a higher interest rate to further encourage payback of thedebt in a timely manner. The payment service system may determine arepayment schedule based on the user's income. As an example and not byway of limitation, the payment service system may identify that a userreceives a paycheck of $1000 bimonthly and determine the user may beable to pay $100 each paycheck for debt from using debt instrumentsthrough a machine learning model. For instance, the machine learningmodel may determine an amount the user typically spends during a monthand determine what portion of the user's paycheck may be allocated topay off debt. The payment service system may generate shorter repaymentschedules based on an amount of the transaction and user's transactionhistory. That is, as an example and not by way of limitation, if theuser requests to access a debt instrument to make a payment for atransaction that is $100 or less, the payment service system maygenerate a repayment schedule that includes a one-time payment of thecost of the transaction. As another example and not by way oflimitation, if the transaction using a debt instrument is for $1000, thepayment service system may generate a repayment schedule of 10 weeks.

In particular embodiments, the payment service system may analyze thetransaction history of a user, size of the user's network (e.g., howmany friends the user conducts transactions with frequently), andthird-party information (e.g., credit bureau information) in order todetermine whether to approve the user of use of a line of credit and/oranother debt instrument. As an example and not by way of limitation, thepayment service system may analyze the transaction history, such asincoming cash flow to determine whether the user already has sufficientfunds to pay for a transaction and determine does not require a pull onthe line of credit in order to pay for a transaction. The paymentservice system may notify the user in response to determining that theuser has sufficient funds in their account for a transaction and doesnot need a pull from a line of credit. As another example and not by wayof limitation, if the user has a large network who the user conductstransactions with frequently (e.g., pay and request money from), thenthe payment service system may determine the user may have a higherprobability of paying off a loan and/or be able to request aid from theuser's network.

In particular embodiments, the payment service system may transmit theset of terms or repayment terms to the user for authorization. After thepayment service system determines a set of terms or repayment termsassociated with a transaction using a debt instrument, the paymentservice system may transmit the set of repayment terms to the user. Asan example and not by way of limitation, the payment service system maysend a request for authorization to a computing device associated withthe user account, such as the user's smartphone. The set of terms orrepayment terms may be presented in a user interface of a mobileapplication associated with the payment service system to display theset of terms or repayment terms for the user to review. In particularembodiments, the payment service provides multiple sets of repaymentterm options and may allow the user to alter one or more of the set ofterms or the repayment terms such that other repayment terms changedynamically. As an example and not by way of limitation, the user maychange the repayment schedule to deduct an amount from the user'sbalance every week instead of every two weeks, or the user may decide topay the amount in full on the payment due date. There may be somerepayment terms that may be unalterable by the user, such as the paymentdue date. In particular embodiments, the user may be allotted a numberof times to extend a payment due date within a year. The number of timesmay be based on the historical repayment data associated with the useraccount. As an example and not by way of limitation, if a user has notmissed a payment, the user may be allotted two payment due dateextensions in a year. In particular embodiments, the payment servicesystem may implement an automatic deduction from the user's balance aspart of the repayment schedule. After the user authorizes the set ofterms or repayment terms, the payment service system may update the useraccount to include the transaction with the set of terms or repaymentterms. As an example and not by way of limitation, after the userauthorizes the repayment terms, the payment service system may post thetransaction with its own repayment terms to the user's account in thetransaction history associated with the user account. In particularembodiments, each transaction may have its own individual repaymentterms. The payment service system may aggregate each transaction withinthe user account associated with one or more debt instruments andreorder the transactions based on a user input. As an example and not byway of limitation, the payment service system may reorder thetransactions by date, by payment due date, by interest rate, by amount,and the like. In particular embodiments, the payment service system maydetermine a time period before a user is charged interest for atransaction using a debt instrument and present that to a user through auser interface within a mobile application associated with the paymentapplication. If the user fails to pay off debt associated with atransaction before the time period, the payment service system may applyan interest rate to the remainder of the debt based on the repaymentterms of the transaction. The payment service system may update the useraccount with any changes. In particular embodiments, the user accountmay be a revolving account that includes dynamic repayment terms foreach transaction.

In particular embodiments, the user may request to borrow an amount fromanother user. As an example and not by way of limitation, the user mayrequest to borrow funds from a friend. The payment service system mayfacilitate the transaction and determine repayment terms associated withthe transaction. The repayment terms may be determined based on thetransaction history of both users. The payment service system may use amachine learning model to be applied to the transaction histories ofboth users to determine repayment terms associated with the transaction.The payment service system may analyze the transaction history of bothuser to determine whether each are eligible for the transaction. As anexample the payment service system may determine whether the user may beable to repay the user after borrowing the amount. The payment servicesystem may also determine whether the lender may have the fundsavailable to loan money to the user. Both of the users may be able tomodify the repayment terms and each user may be requested to authorizethe final repayment terms. A user may extend an offer to another user toborrow money from the user. This may ignore the eligibilitydetermination of the borrower because the lender is extending the offer.In particular embodiments, the payment service system may determine anoptimum time for users to request to borrow an amount from another user.As an example and not by way of limitation, if a user attempts torequest money from another user, the payment service system maydetermine whether the potential lender has the sufficient funds for therequestor. The payment service system may determine the potential lenderdoes not have sufficient funds at the moment, but usually gets paid on acertain day of the month and notify the user to request at a later date.In particular embodiments, depending on transaction history betweenusers, the payment service system may notify the user of specificdetails of when to request. As an example and not by way of limitation,if two users frequently pay and request money from each other (e.g.,indicating a strong relationship), then the payment service system maynotify the requestor that the potential lender typically does not getpaid until the end of the month. However, if the two users do not havefrequent transactions between the two, then the payment service systemmay indicate to the user that currently is not a best time to requestand/or simply deny the request to borrow money from the potentiallender.

In particular embodiments, the repayment terms may comprise a setpercentage or an amount to subtract from incoming cash. As an exampleand not by way of limitation, instead of paying an amount every week(e.g., $20 every Friday) for a set term, a user may select (if theoption is enabled for the user) to have a percentage of incoming moneyto be deducted in order to pay back a transaction, loan, etc. Forinstance, if a user decides to borrow $100 and chooses to pay through apercentage of incoming money, then whenever money is sent to the user, apercentage (e.g., 10% of the money) is taken out to repay the borrowedmoney until the loan is repaid. In particular embodiments, the option toselect a set percentage may be offered to users based on transactionhistory, repayment history, and other parameters. In particularembodiments, the repayment of a loan may have the repayment termsupdated so it may switch from a set amount every week (e.g., $20 everyweek) to a set percentage of incoming money (e.g., 5% every time moneyenters a user's account). The user may be offered by the payment servicesystem after the payment service system determines the user may beeligible. As an example and not by way of limitation, the user mayrequest to switch in the instance the user lost their job and thepayment service system may determine the user is eligible. One or moretransactions that need to be repaid may switch repayment terms based ona determination of eligibility by the payment service system. Inparticular embodiments, if the user is borrowing from another user, thepotential lender may offer the option and/or the borrower may request torepay the potential lender through a percentage of incoming money.

In particular embodiments, the payment service system may consolidatemultiple transactions that each have their own repayment terms. As anexample and not by way of limitation, if a user has two transactionswith different repayment terms, the payment service system may combinethe two transactions so the user will only have to repay onetransaction. The payment service system may calculate new repaymentterms for the consolidated transaction. In particular embodiments, theuser may request to consolidate two or more transactions each with theirrespective repayment terms. In particular embodiments, if two or moretransactions have the same repayment terms (e.g., they have the defaultrepayment terms), then the two or more transactions may be combined bydefault. In particular embodiments, an event may trigger a consolidationof multiple transactions. When the payment service system detects theevent, the event may trigger a consolidation of two or more transactionswith new repayment terms to be presented to the user for authorization.As an example and not by way of limitation, the payment service systemmay detect that a user has an increase in income through a third-party(e.g., a bank) and may be able to pay off more debt at a given time. Ifthe user is a merchant, the event may be a new employee added to thepayroll of the merchant or an increase in sales activity compared to ahistorical trend. In response to the event, the payment service systemmay generate a new consolidated transaction offer, where theconsolidated transaction offer combines two or more transactions thatneed to be repaid with new repayment terms. The consolidated transactionoffer may be presented to the user to be accepted. Upon authorizationfrom the user (e.g., the user accepts the consolidated transactionoffer), the payment service system may update the user account to showthe new consolidated transaction offer. The consolidated transactionoffer may have repayment terms that change based on the detected event.As an example and not by way of limitation, if the payment servicesystem detects that the user has an increased cash flow this month(e.g., the user deposits a large amount of money), then the paymentservice system may generate a consolidated transaction offer toconsolidate multiple transactions to be repaid with more favorable terms(e.g., reduced interest rate with a shortened repayment schedule) toencourage the user to pay off the multiple transactions faster.

In particular embodiments, the payment service system may sendnotifications to a user through the user's computing device to remindthe user of scheduled repayments. The user may opt-in or opt-out of anautomatic scheduled deduction of the user's balance. In particularembodiments, the user's ability to opt-in or opt-out of an automaticscheduled deduction of the user's balance may be based on a risk levelof the user. As an example and not by way of limitation, if the user isclassified as a high-risk user, the payment service system 108 mayprevent the user from opting out of the automatic scheduled deduction ofthe user's balance.

In particular embodiments, machine learning algorithms may be used tobuild a mathematical model of sample data, known as “training data”, inorder to make predictions or decisions without being explicitlyprogrammed to perform the task. In particular embodiments, a computingsystem (e.g., computing systems associated with a payment servicesystem) may leverage machine learning models to improve the efficiencyand effectiveness of transaction data analysis. Transaction dataanalysis may include the analysis of any suitable transaction data, suchas prior transactions, transaction histories of users, transactions of aparticular category, etc. Additionally, these machine learning modelsmay analyze user profiles, user repayment histories, transaction profilecharacteristics in order to determine a level of risk associated witheach transaction. The machine learning model may be trained on aplurality of transaction examples each having their own correspondinguser profile, user repayment history, and transaction profilecharacteristics. As an example and not by way of limitation, the machinelearning model may be trained to identify a risk level of a userprofile. For instance, a person who pays off debt on time or in advanceand has a substantial balance to pay off debt may be classified as alow-risk user profile. As such, any transaction this particular usermakes would generally be classified as low risk. The machine learningmodel may determine one or more flexible repayment schedules for theuser to following in paying off debt.

In particular embodiments, the machine learning models may besupervised, semi-supervised, or unsupervised. The machine learningmodels may be based on regression learning, reinforcement learning,decision trees, random forest, support vector machines, neural networks,or any suitable learning algorithms. In particular embodiments, thecomputing system may use neural network based machine learning modelsfor transaction data analysis. As an example and not by way oflimitation, the neural network based models may comprise one or more ofconvolutional neural networks, long-short term memory units, orrecurrent neural networks, or any combination thereof.

A neural network is a system of interconnected artificial “neurons” thatexchange messages between each other. The connections have numericweights that are tuned during the training process, so that a properlytrained network will respond correctly when presented with an image orpattern to recognize. The network consists of multiple layers offeature-detecting “neurons”. Each layer has many neurons that respond todifferent combinations of inputs from the previous layers. Training of anetwork is performed using a “labeled” dataset of inputs in a wideassortment of representative input patterns that are associated withtheir intended output response. Training uses general-purpose methods toiteratively determine the weights for intermediate and final featureneurons. In terms of a computational model, each neuron calculates thedot product of inputs and weights, adds the bias, and applies anon-linear trigger function (for example, using a sigmoid responsefunction). Deep neural networks (DNN) have shown significantimprovements in several application domains.

In particular embodiments, the payment service system may increase thenetwork speed and increase bandwidth across the network throughimplementation of dynamically generating repayment terms for atransaction by determining optimal repayment terms for a user to repaydebt associated with the transaction. By determining the optimalrepayment terms for a user to repay debt using a machine learning model,the payment service system reduces the amount of users reapplying forloans after being denied. Additionally, the payment service systemreduces the amount of users defaulting on repaying debt through the useof a machine learning model to optimize repayment of debt. Thereby,reducing the amount of resources needed to collect payment from usersthat have defaulted. The payment service system may reduce networkbandwidth consumed through enhancing distributed systems by using datastructures to intelligently adjust balances of users and merchantscorresponding to transactions. As an example and not by way oflimitation, a user may opt-in to schedule automatic repayment of atransaction using a debt instrument, which the payment service systemmay adjust balances of users based on the generated repayment terms. Inparticular embodiments, consolidation of multiple transactions to berepaid, may reduce the amount of resources used to manage thetransactions by combining the multiple transaction into one consolidatedtransaction. The payment service system may, as a result ofconsolidating transactions, need to process one transaction as opposedto multiple transactions (e.g., transfer funds from user account asingle time as opposed to multiple times for several transactions and atdifferent times).

The embodiments disclosed herein are only examples, and the scope ofthis disclosure is not limited to them. Particular embodiments mayinclude all, some, or none of the components, elements, features,functions, operations, or steps of the embodiments disclosed above.Embodiments disclosed in the attached claims directed to a method, astorage medium, a system and a computer program product, wherein anyfeature mentioned in one claim category, e.g., method, may be claimed inanother claim category, e.g., system, as well. The dependencies orreferences back in the attached claims are chosen for formal reasonsonly. However, any subject matter resulting from a deliberate referenceback to any previous claims (in particular multiple dependencies) may beclaimed as well, so that any combination of claims and the featuresthereof are disclosed and may be claimed regardless of the dependencieschosen in the attached claims. The subject matter which may be claimedcomprises not only the combination of features as set out in theattached claims but also any other combination of features in theclaims, wherein each feature mentioned in the claims may be combinedwith any other feature or combination of other features in the claims.Furthermore, any of the embodiments and features described or depictedherein may be claimed in a separate claim and/or in any combination withany embodiment or feature described or depicted herein or with any ofthe features of the attached claims.

FIG. 1A illustrates an example payment service system networkenvironment 100. Merchant 102 may conduct transactions with customer 104(or “user 104”) for items 106 offered by the merchant 102. FIG. 1A alsoillustrates a payment service system 108 (also referred to as “paymentservice”), coupled to merchant point-of-sale (POS) device 105 andcustomer device 103 via a network 110-1, to authorize paymentinstruments of customer 104.

Customer 104 may engage in transactions with merchant 102 to purchaseitems (e.g., goods or services offered by the merchant 102) 106.Customer 104 may provide, as shown at 112, cash or any other kind ofpayment instruments to merchant 102 along with requests for itemsoffered by merchant 102.

Merchant 102 may utilize POS device 105 for accepting payment fromcustomers 104. POS device 105 may comprise any sort of mobile ornon-mobile devices that include instances of a merchant application thatexecutes on the devices. The merchant application may provide POSfunctionality to POS device 105 to enable merchant 102 (e.g., owners,employees, etc.) to accept payments from customers 104. In some types ofbusinesses, POS device 105 may correspond to a store or other place ofbusiness of the merchant, and thus, may be a fixed location thattypically does not change on a day-to-day basis. In other types ofbusinesses, however, the location of POS device 105 may change from timeto time, such as in the case that a merchant operates a food truck, is astreet vendor, is a cab driver, etc., or has an otherwise mobilebusiness, e.g., in the case of a merchant who sells items at buyer'shomes, places of business, and so forth.

As used herein, a merchant may include any business engaged in theoffering of goods or services for acquisition by customers. Actionsattributed to a merchant may include actions performed by owners,employees, or other agents of the merchant, and thus no distinction ismade herein unless specifically discussed. In addition, as used herein,a customer may include any entity that acquires goods or services from amerchant, such as by purchasing, renting, leasing, borrowing, licensing,or the like. Hereinafter, goods and/or services offered by merchants maybe referred to as items, e.g., item 106. Thus, a merchant and a customermay interact with each other to conduct a transaction in which thecustomer acquires item 106 from merchant 102, and in return, customer104 provides payment 112 to merchant 102.

As used herein, a transaction may include a financial transaction forthe acquisition of item(s) that is conducted between customer 104 andmerchant 102. For example, when paying for a transaction, customer 104may provide the amount that is due to the merchant using cash or otherpayment instrument 112 (e.g., a debit card, a credit card, astored-value or gift card, a check, through an electronic paymentapplication 107 on device 103 carried by the customer, or the like). Themerchant may interact with POS device 105 to process the transactions,such as by inputting (e.g., manually, via a magnetic card reader, NFCreader, or an RFID reader, etc.) identifiers associated with paymentinstrument 112. For example, a payment instrument of the customer mayinclude a card having one or more magnetic strips for providing card andcustomer information when swiped in a card reader. In other examples,other types of payment instruments may be used, such as smart cardshaving a built-in memory chip that is read by the device when the cardis inserted into the reader, such as chips that comply with the Europay,MasterCard, Visa (EMV) standard, i.e., EMV cards. In other examples,other types of payment instruments include cards or computing devicesthat communicate via radio frequencies such as a radio frequencyidentification tags, and near field communication devices, etc. In otherexamples, other types of payment instruments may include debtinstruments, such as a credit card or a line of credit.

During the transaction, POS device 105 may determine transactioninformation describing the transaction, such as the identifier of thepayment instrument, an amount of payment received from the customer, theitem(s) acquired by the customer, a time, place and date of thetransaction, a payment network 140 associated with the paymentinstrument, an issuing bank of the payment instrument, a name or useraccount of the customer, contact information of the customer, type ofthe currency, and so forth. POS device 105 may send the transactioninformation to payment service system 108 over network 110-1, eithersubstantially contemporaneously with the conducting of the transaction(in the case of online transactions) or later when POS device 105 is inthe online mode (as in the case of offline transactions). In particularembodiments, the transaction information may comprise the purchasecharacteristics of the transaction.

In an offline transaction, POS device 105 may store one or morecharacteristics associated with the transaction (i.e., the transactioninformation), such as a cost of the transaction, a time of day at whichthe transaction occurred, a day of the week at which the transactionoccurred, a location at which the transaction took place, an item thatthe customer obtained, identity and/or contact information of thecustomer, and a payment instrument used in the transaction. Afterconducting an offline transaction with customer 104, POS device 105 mayprovide the stored information (or some subset of it) to the paymentservice system 108 over the network 110-1. The network 110-1 mayrepresent any one or more wired or wireless networks, such as a Wi-Finetwork, a cellular network, or the like. In an online transaction, POSdevice 105 may send this information to payment service system 108 overnetwork 110-1 substantially contemporaneously with the transaction withthe customer.

After merchant 102 receives the payment information from customer 104,merchant 102 may send respective authorization requests, along withinformation regarding the respective transactions, to payment servicesystem 108, as illustrated at 114. Payment service system 108 mayinclude payment processing service 126, merchant profiles 130, andcustomer profiles 132. Here, the merchant profiles 130 may compriseinformation about one or more merchants using the payment service system108. The customer profiles 132 may comprise information about one ormore customers using the payment service system 108. Each merchant orcustomer may otherwise be called a user of the payment service system108. A particular user may be a merchant, a customer, or eitherdepending on the use case.

The payment processing service 126 may receive the information regardinga transaction from POS device 105 of merchant 102 and attempt toauthorize the payment instrument used to conduct the transaction.Payment processing service 126 may then send an indication of whetherthe payment instrument has been approved or declined back to POS device105, as illustrated at 116.

When a customer and a merchant enter into an electronic paymenttransaction, the transaction may be processed by electronicallytransferring funds from a financial account associated with the customerto a financial account associated with the merchant. As such, thepayment processing service 126 may communicate with one or morecomputing devices of a payment card network 140 (or “card paymentnetwork”), e.g., MasterCard®, VISA®, over network(s) 110-2 to conductfinancial transactions electronically. Payment processing service 126may also communicate with one or more computing devices of one or morebanks, processing/acquiring services, or the like over the network110-2. For example, payment processing service 126 may communicate withan acquiring bank, and/or an issuing bank, and/or a bank maintainingcustomer accounts for electronic payments. Payment processing service126 may also communicate with, or access customer and merchant accountsmaintained by payment service system 108.

An acquiring bank may be a registered member of a card association(e.g., Visa®, MasterCard®), and may be part of a card payment network140. An issuing bank may issue credit cards to buyers and may payacquiring banks for purchases made by cardholders to which the issuingbank has issued a payment card. Accordingly, in some examples, thecomputing device(s) of an acquiring bank may be included in the cardpayment network and may communicate with the computing devices of acard-issuing bank to obtain payment. Further, in some examples, thecustomer may use a debit card instead of a credit card, in which case,the bank computing device(s) of a bank corresponding to the debit cardmay receive communications regarding a transaction in which the customeris participating. Additionally, there may be computing devices of otherfinancial institutions involved in some types of transactions or inalternative system architectures, and thus, the foregoing are merelyseveral examples for discussion purposes.

In transactions involving cryptocurrency, payment service system 108 maycommunicate over network(s) with one or more cryptocurrency networks.Such networks may include for example, the Bitcoin network, the Ethereumnetwork, etc. Cryptocurrency networks are associated with a network ofparties that cryptographically verify and validate transactions andrecord transactions on copies of a distributed ledger commonly calledthe blockchain. Once a transaction has been validated, a cryptocurrencynetwork may approve the transaction by writing the transaction to theblockchain. The time for such processes to complete may be impracticallylong for many applications.

Networks 110-1, 110-2 may represent any one or more wired or wirelessnetworks, such as a Wi-Fi network, a cellular network, a wide areanetwork, a local area network, or the like. For the purposes ofillustration, networks 110-1, 110-2 are shown as separate networks. Inparticular embodiments, networks 110-1, 110-2 may be the same network,subnets of the same network, one or more separate networks, or othersuitable arrangement.

While FIG. 1A illustrates merchants 102 sending the transaction datadirectly to the payment service system 108 as part of the request toauthorize the payment instrument, in some instances other entities(e.g., banks associated with the merchants or with customer paymentinstruments) may provide transaction data, such as part of a batched,periodic process.

While customer profiles 132 may store indications of user preferences,merchant profiles 130 may store information associated with respectiveprofiles of the merchants 102. For instance, the merchant profiles 130may indicate a class or category of items offered by respectivemerchants (e.g., coffee items, collectibles, apparel, etc.), a type ofbusiness of the merchant (e.g., restaurant, coffee shop, retail store,etc.), a geographical location of the merchant, and the like.

In some instances, a computing device associated with the merchant(e.g., POS device 105, servers of the merchant, etc.) may determine whenthe customer visits physical premises or a digital presence of themerchant. For instance, the device 103 of the customer 104 may includean application 107 (e.g., an application provided by payment servicesystem 108) that communicates with POS device 105 of merchant 102 vianear-field communication methods (e.g., Bluetooth, etc.). Therefore,when the customer visits the physical premises of merchant 102, forexample, POS device 105 may detect the presence of customer device 103.The POS device may accordingly determine that the customer is present.In another example, one or both of POS device 105 and customer device103 may share its location (e.g., GPS coordinates) to a common servicefor determining when the devices are located within a thresholdproximity of one another, and for mediating a transaction betweencustomer device 103 and POS device 105.

In another example, customer 104 may utilize customer device 103 to“check in” at the merchant location, and POS device 105 may receive anindication of this check in. When the customer visits a digital presenceof merchant 102 (e.g., a website, etc.), customer 104 may log in orotherwise provide information (e.g., a cookie on the device 103) fromwhich the merchant determines that the customer is at the merchant. Ofcourse, while a few examples are listed, it is to be appreciated thatthe merchant and/or payment service system 108 may determine when thecustomer is present at the merchant in any other number of ways. In eachinstance, after payment service system 108 receives an indication thatcustomer 104 is located at merchant 102, the payment service system 108may determine whether to send one or more previously expressed itempreferences of the customer to the merchant.

In addition, customer 104 may desire to receive an instance of apayments application 107, such as a mobile wallet application, from thepayment service system 108. FIG. 1A illustrates, at 118, that thecustomer 104 may send payment-application requests to payment servicesystem 108. In response, at 120, payment service system 108 may provideinstances of the application 107 back to customer device 103. Inaddition, payment service system 108 may map an identification of theinstance of the application 107 to the customer profile.

According to an implementation of the present subject matter, thecustomers and merchants may send and receive payments in security assetsvia the payment service system for purchase of items or a selected setof items. In another implementation, the customers may send payments insecurity assets via the payment service system, while the paymentservice system converts a security asset into another asset of themerchant's choice. In another implementation, the customers maydesignate particular security assets to be sold with the express purposeof putting some or all of the proceeds from the sale towards settling abill with the merchants.

FIG. 1B illustrates another embodiment of example environment 100. FIG.1B includes many of the same components as the embodiment of exampleenvironment 100, except that in FIG. 1B a transaction is between anoperating device 152 of a first user 150, and an operating device 156 ofa second user 154. For all other components, the descriptions above withrespect to at least FIG. 1A apply. Devices 152 and 156 may be acomputing device with applications 153 and 157, respectively, providedby payment service system 108 executing thereon. In some embodiments,one or more of the applications 153 and 157 may be point-of-saleapplications. In some embodiments, one or more of the applications 153and 157 may be mobile wallet applications. In some embodiments, one ormore of the applications 153 and 157 may be applications provided by athird party capable of accessing at least one payment account.

FIG. 1B illustrates a broader concept—that the present technologycontemplates that currency or assets may be sent from any party of anycharacter (merchant, user, bank, etc.) to any other party of anycharacter using the innovations described herein.

In particular, any of the examples described as interactions ortransactions between a merchant and a user may be performed between twousers 150 and 154. According to an implementation of the present subjectmatter, the users 150 and 154 may send and receive payments in securityassets via the payment service system 108 for purchase of items or aselected set of items. In another implementation, a user 150 may sendpayments in security assets via the payment service system 108, whilethe payment service system 108 converts the security asset from thefirst user 150 into another asset of the second user's 154 choice. Inanother implementation, the first user 150 may designate particularsecurity assets to be sold with the express purpose of putting some orall of the proceeds from the sale towards settling a bill with thesecond user 154. In another implementation, the first user 150 maydesignate particular security assets to be sold with the express purposeof putting some or all of the proceeds from the sale towards providing aloan to the second user 154 through the payment service system. In thisimplementation, the first user 150 may designate a requested form ofrepayment (e.g., repayment in a particular currency, the same securityasset, one or more other specified security assets, any other securityassets, or a mixture of different security assets, types of the securityassets, or security assets and currency). The second user 154 may repaythe loan provided by the first user 150 through the payment service. Thepayment service system 108 may facilitate fulfillment of the requiredform of repayment by automatically converting a payment option providedby the second user 154 (e.g., currency or a designate amount of asecurity asset) to the designated security required form of repayment.The payment service system allows for a more expansive array of paymentoptions, transactions that are completed more quickly and accurately byreducing the communication and processing times needed for computingsystems of various parties to authorize and process the transactions andsimplifies the interactions and interfaces that a user must engage within order to prepare and request the transactions. Taken together, theseimprovements amount to an overall improvement over previous paymentprocessing systems and related devices. The payment service systemtherefore includes significant technical advantages and improvementsover previous devices.

FIG. 2 illustrates an example system architecture for a payment servicesystem 108. In particular embodiments, the payment service system 108may store customer profile 132 for each of a plurality of customers.Customer profile 132 may include customer data 201 that may includecustomer-identifying information (name, contact information,demographical data, etc.), a transaction log 202 including records ofpast transactions involving payment service system 108 by customer 104,information regarding linked accounts (credit card information, bankaccount information, etc.), information regarding services utilized bycustomer profile 132 (e.g., a mobile wallet application). The customerdata 201 may further comprise information associated with one or moresocial or peer-to-peer contacts of a user (e.g., friends, familymembers, online network connections). The information may comprise atleast part of the profile information of such contacts.

The customer profile 132 may also include a ledger for any accountsmanaged by payment service system 108 on behalf of customer 104. It willbe appreciated that customers having accounts managed by the paymentservice system 108 is an aspect of the technology that enables technicaladvantages of increased processing speed and improved security. Forexample, the customer profile 132 may include a currency ledger 203. Thecurrency ledger 203 may store a balance for each of one or morecurrencies (e.g., US dollar, Euro, bitcoin) that the customer owns. Thecurrency ledger may include information regarding one or more separateaccounts of the user that each include currency owned by the customer.The payment service system 132 may also manage or maintain one or morecurrency accounts 204 on behalf of the user. The currency accounts 204may include a logical division of currency held by the payment servicesystem 108 that is allocated for the customer's use. The customerprofile 132 may also include a debt ledger 205. The debt ledger 205 maystore a balance for each of one or more debt instruments (e.g., creditcard, line of credit, loan) that the customer owns. The debt ledger mayinclude information regarding one or more separate debt accounts 206 ofthe user that each include debt instruments owned by the user. Thepayment service system 108, or one or more third-parties acting onbehalf of the payment service system 108, may manage and maintain thedebt accounts 206 for the user. The debt accounts 206 may include alogical division of debt instruments held by the payment service system108 that is allocated for the customer's use. The currency ledger 203and the debt ledger 205 may utilize any suitable data structure. As anexample and not by way of limitation, a separate ledger may be used torecord information about each individual asset or debt owned by thecustomer. Various ledgers associated with a particular customer may bestored all together, in groups, or separately. As another example andnot by way of limitation, the currency ledger 203 and the debt ledger205 may be logical ledgers. The associated the ledgers may all be savedin a single file, data set, or database. In other words, a customer'sownership interest in a plurality of types of assets (e.g., fiatcurrency, cryptocurrency, security assets) may all be recorded in acomposite ledger or be separately recorded in a plurality of ledgers.

Each account ledger (203, 205) may reflect a positive balance ornegative balance when customer 104 funds or pulls from the accounts(204, 206). An account may be funded by transferring currency in theform associated with the account from an external account (e.g.,transferring a quantity of cash to payment service system 108 and thevalue is credited as a balance in currency ledger 203), or by purchasingcurrency in the form associated with the account from the paymentservice system 108 using currency in a different form, or by conductinga transaction with another user (customer or merchant) of the paymentservice system 108 wherein the account receives incoming currency. Anaccount may be funded by receiving a request to access a debtinstrument. When a customer requests to access a debt instrument fromthe payment service system 108, the payment service system 108 may debita balance stored in the currency account 204 or on the currency ledger203 and credit a balance stored in the debt account 206 or on the debtledger 205.

Similarly, as introduced with respect to FIGS. 1A and 1B, paymentservice system 108 may store merchant profile 134. The merchant profile134 may comprise merchant data 207, transaction log 208, currency ledger209, currency account 210, debt ledger 211, and debt account 212. Themerchant data 207 may comprise one or more preference settingsassociated with the merchant 102, such as a type of currency or assetthat the merchant prefer to receive as payment. The information storedin the merchant profile 134 may be made accessible and managed by amerchant 102 through a POS device 105 or other suitable devicesassociated with the merchant 102. Operations, including maintenance andmanagement operations, described with respect to the customer profile132 and information included therein (e.g., the customer data 201,transaction log 202, currency ledger 203, currency account 204, debtledger 205, and debt account 206) are as much applicable to the merchantprofile 134 and the information included therein (e.g., the merchantdata 207, transaction log 208, currency ledger 209, currency account210, debt ledger 211, and debt account 212).

The payment service system 108 may maintain a currency ledger 213recording a quantity of cash or other currencies held by the paymentservice system 108. The quantity of cash or other currencies held by thepayment service system may, for example, be held in one or more currencyaccounts 214. The payment service system may maintain a debt ledger 215recording a quantity of debt instruments held by the payment servicesystem 108. The quantity of debt instruments held by the payment servicesystem 108 may, for example, be held in one or more debt accounts 216.The currency ledger 213 and the debt ledger 215 may also specify theportion of the assets held by the payment service system 108 (e.g.,through the currency accounts 214 and debt accounts 216) that is ownedby one or more users of the payment service system 108 and the portionof the assets that is owned by the payment service system 108. When thepayment service system 108 has its own holdings of debt instruments,customers may request access to debt instruments directly from thepayment service system 108.

When two users (e.g., users 150 and 154) engage in a transaction thatinvolves a transfer of assets, such a transaction may be reflected onthe ledgers associated with each customer's profile 132. As an exampleand not by way of limitation, a first user 150 may transfer a quantityof currency assets to a second user 154. The payment service system 108may accordingly debit the currency ledger 203 (and correspondingcurrency account 204) of the first user 150 and credit the currencyledger 203 (and corresponding currency account 204) of the second user154.

Additionally, customer 104 may also have one or more external paymentcards registered with payment service system 108. The external paymentcards may be associated with external bank accounts 222. The externalpayment card accounts may not be managed by payment service system 108.Instead, an appropriate external payment network 224 may processtransactions conducted with payment cards.

Additionally, customer 104 may also have one or more internal paymentcards registered with payment service system 108. Internal payment cardsmay be linked to all accounts associated with customer profile 132. Insome embodiments, options with respect to internal payment cards may beadjusted and managed using a payment application 107 installed on thecustomer device 103. For example, when customer profile 132 includesmultiple payment accounts (e.g., cryptocurrency, fiat currency, and debtinstruments), application 107 may set one of those accounts to be thedefault account for debits or credits when using an internal paymentcard.

Customer 104 may access and monitor customer profile 132 includingpayment cards registered with payment service system 108, currencyledger 203, currency account 204, debt ledger 205, and debt account 206through the application 107 installed on the customer device 103. Theapplication 107 may be a customer facing application provided by paymentservice system 108, or that is configured to access customer profile 132through use of one or more APIs provided by payment service system 108.In some embodiments, application 107 on the customer device 103 mayprovide digital wallet functionality including storing payment methodsand permitting electronic payments by customer device 103 at theinstruction of application 107.

The payment service system 108 may receive user settings regarding acurrency account. For example, a user may set a balance limit for thecurrency account. The balance limit may be a require balance for thecurrency account.

FIGS. 3A-3B illustrate the interactions between various actors,including the payment service system 320 and a user device 310, in aprocess for generating repayment terms for a transaction. In reviewingFIG. 3A, the process generally advances as the blocks representing stepsof the process proceed from the top of the figure downward so that, evenif an arrow does not connect blocks, a first block (e.g., the block forstep 312) above a second block (e.g., the block for step 323) willgenerally occur first in the process. The process may begin at step 321,in which a payment service system 320 may generate default repaymentterms to be associated with a user account. The payment service system320 may analyze the user's transaction history and determine the user isrunning low on funds and determine the user may need a line of credit.At step 322, the payment service system 320 may send an initial line ofcredit to the user, which will be available for the user to access. Theuser device 310 may receive the access to the line of credit withdefault repayment terms. The user device 310 may display the line ofcredit to the user in an application. At step 312, the user device 310may receive a request to access a debt instrument to make a payment fora transaction. For example, a user may input a request in an applicationto access a debt instrument. As another example, the user may use apayment card (i.e., a debt instrument) to pay for a transaction. Theuser device 310 may send the request to the payment service system 320in step 313. After the payment service system 320 receives the request,in step 323, the payment service system 320 may identify purchasecharacteristics of the transaction. In particular embodiments, thepayment service system 320 may extract the purchase characteristics fromthe transaction details or request the purchase characteristics from themerchant. After the payment service system 320 extracts the purchasecharacteristics, the payment service system 320, in step 324, maydetermine whether the transaction is eligible for modified repaymentterms based on purchase characteristics. In step 325, if the transactionis not eligible then the process may proceed to step 314, where the userdevice 310 presents default repayment terms for user authorization. Instep 325, if the transaction is eligible, the process proceeds to step326 of FIG. 3B, where the payment service system 320 may use a machinelearning model applied to the identified purchase characteristics togenerate repayment terms associated with the request. For example, thepayment service system 320 may determine an interest rate associatedwith the transaction based on the purchase characteristics. At step 327,the payments service system 320 may transmit the repayment terms to theuser device 310 for authorization of repayment terms. After the userdevice 310 receives the repayment terms, at step 315, the user device310 presents the repayment terms for user authorization. At step 316, adetermination of whether the user device 310 receives authorization or arejection may be made. If the user rejects the repayment terms, theprocess proceeds to step 328, where the user device 310 sends over theuser rejection to the payment service system 320 and the payment servicesystem 320 may reject the request to access the debt instrument to makea payment for the transaction. If the user authorizes the repaymentterms by approving the repayment terms, the process proceeds to step329, where the user device 310 sends over the user authorization to thepayment service system 320 and the payment service system 320 may updatethe user account associated with the user device 310 to include thetransaction with the repayment terms. This may include establishing arepayment schedule with a determined fee associated with the transactionand an interest rate charged to any leftover amount if the user isdelinquent on paying off the debt. The process further enablessignificant new interactions because the user device and the paymentservice system as described throughout.

FIGS. 4A-4B illustrate the interactions between various actors,including the payment service system 420, a user device 410, and amerchant device 430, in a process for generating repayment terms for atransaction using a payment card. In reviewing FIG. 4A, the processgenerally advances as the blocks representing steps of the processproceed from the top of the figure downward so that, even if an arrowdoes not connect blocks, a first block (e.g., the block for step 431)above a second block (e.g., the block for step 422) will generally occurfirst in the process. The process may begin at step 431, in which amerchant device 430 may receive a request to make a payment for atransaction with a payment card. Then, at step 432, the merchant device430 may send a request to transfer funds to pay for the transaction andtransaction details associated with the transaction. The request totransfer funds may be associated with the payment card used in thetransaction. At step 421, the payment service system 420 may identify auser account associated with the payment card. The payment servicesystem 420 may identify the purchase characteristics of the transaction.In particular embodiments, the payment service system 420 may extractthe purchase characteristics from the transaction details or request thepurchase characteristics from the merchant. After the payment servicesystem 420 extracts the purchase characteristics, the payment servicesystem 420, in step 423, may determine whether the transaction iseligible for modified repayment terms based on purchase characteristics.In step 424, if the transaction is not eligible then the process mayproceed to step 411, where the user device 410 presents defaultrepayment terms for user authorization. In step 424, if the transactionis eligible, the process proceeds to step 425 of FIG. 4B, where thepayment service system 420 may use a machine learning model applied tothe identified purchase characteristics to generate repayment termsassociated with the request. For example, the payment service system 420may determine an interest rate associated with the transaction based onthe purchase characteristics. At step 426, the payments service system420 may transmit the repayment terms to the user device 410 forauthorization of repayment terms. After the user device 410 receives therepayment terms, at step 412, the user device 410 presents the repaymentterms for user authorization. At step 413, a determination of whetherthe user device 410 receives authorization or a rejection may be made.If the user rejects the repayment terms, the process proceeds to step427, where the user device 410 sends over the user rejection to thepayment service system 420 and the payment service system 420 may rejectthe request to access make a payment for the transaction using thepayment card. After the payment service system 420 rejects the request,the payment service system 420 may send a rejection to the merchantdevice, where, at step 433, the merchant device 430 may deny the requestto transfer funds to pay for the transaction. If the user authorizes therepayment terms by approving the repayment terms, the process proceedsto step 428, where the user device 410 sends over the user authorizationto the payment service system 420 and the payment service system 420 mayupdate the user account associated with the user device 410 to includethe transaction with the repayment terms. After the user account isupdated, at step 434, the merchant device 430 may receive a transfer ofthe funds to the merchant to pay for the transaction. This may includeestablishing a repayment schedule with a determined fee associated withthe transaction and an interest rate charged to any leftover amount ifthe user is delinquent on paying off the debt. The process furtherenables significant new interactions because the user device, thepayment service system, and the merchant device as described throughout.

FIGS. 5A-5B illustrate the interactions between various actors,including the payment service system 520 and a user device 510, in aprocess for generating repayment terms for accessing a line of credit.In reviewing FIG. 5A, the process generally advances as the blocksrepresenting steps of the process proceed from the top of the figuredownward so that, even if an arrow does not connect blocks, a firstblock (e.g., the block for step 511) above a second block (e.g., theblock for step 522) will generally occur first in the process. Theprocess may begin at step 511, in which a user device 510 may receive arequest for a cash advance from a line of credit associated with theuser account. Then, at step 512, the user device 510 may send a requestto for the cash advance to the payment service system 520. At step 521,the payment service system 520 may identify a transaction history of theuser account and transaction characteristics of the transaction. Afterthe payment service system 520 identifies the transaction history andtransaction characteristics, the payment service system 520, in step522, may determine whether the transaction is eligible for modifiedrepayment terms based on the transaction history and the transactioncharacteristics. In step 523, if the transaction is not eligible thenthe process may proceed to step 513, where the user device 510 presentsdefault repayment terms for user authorization. In step 513, if thetransaction is eligible, the process proceeds to step 524, where thepayment service system 520 may use a machine learning model applied tothe identified information to generate repayment terms associated withthe request. For example, the payment service system 520 may determinean interest rate associated with the transaction based on thetransaction history and the transaction characteristics. At step 525,the payments service system 520 may transmit the repayment terms to theuser device 510 for authorization of repayment terms. After the userdevice 510 receives the repayment terms, at step 514, the user device510 presents the repayment terms for user authorization. At step 515 ofFIG. 5B, a determination of whether the user device 510 receivesauthorization or a rejection may be made. If the user rejects therepayment terms, the process proceeds to step 526, where the user device510 sends over the user rejection to the payment service system 520 andthe payment service system 520 may reject the request for a cash advancefrom the line of credit. If the user authorizes the repayment terms byapproving the repayment terms, the process proceeds to step 527, wherethe user device 510 sends over the user authorization to the paymentservice system 520 and the payment service system 520 may update theuser account associated with the user device 510 to include thetransaction with the repayment terms. This may include establishing arepayment schedule with a determined fee associated with the transactionand an interest rate charged to any leftover amount if the user isdelinquent on paying off the debt. The process further enablessignificant new interactions because the user device and the paymentservice system as described throughout.

FIGS. 6A-6C illustrate the interactions between various actors,including the payment service system 620, a first user device 610, and asecond user device 630 in a process for generating repayment terms forborrowing from another user. In reviewing FIG. 6A, the process generallyadvances as the blocks representing steps of the process proceed fromthe top of the figure downward so that, even if an arrow does notconnect blocks, a first block (e.g., the block for step 611) above asecond block (e.g., the block for step 622) will generally occur firstin the process. The process may begin at step 511, in which a first userdevice 610 may receive a request for to borrow an amount from a seconduser. Then, at step 612, the first user device 610 may send a request toborrow the amount to the payment service system 620. At step 621, thepayment service system 620 may identify a transaction history of theuser account associated with the first user. After the payment servicesystem 620 identifies the transaction history, the payment servicesystem 620, in step 622, may use a machine learning model applied to thetransaction history to determine whether the first user is eligible toborrow the requested amount. In step 623, if the first user is noteligible, then the process proceeds to step 613, where the first userdevice 610 receives a rejection of request to borrow the amount. In step623, if the first user is eligible, then the process may continue tostep 624, where the payment service system 620 may identify a useraccount and transaction history associated with the second user. At step625 of FIG. 6B, the payment service system may use a machine learningmodel applied to the transaction history of the second user to determinewhether the second use is eligible to lend the requested amount. In step626, if the second user is not eligible, then the process proceeds tostep 614, where the first user device 610 receives a rejection ofrequest to borrow the amount. In step 626, if the second user iseligible, then the process proceeds to step 627, where the paymentservice system 620 uses a machine learning model applied to thetransaction histories of both the first user and the second user togenerate modified repayment terms. At step 628 of FIG. 6C, the paymentservice system 620 may transmit the modified repayment terms to thesecond user for authorization. In step 631, a determination of whetherthe second user device 630 receives authorization or a rejection may bemade. If the second user rejects the repayment terms, the processproceeds to step 629, where the second user device 630 sends over theuser rejection to the payment service system 620 and the payment servicesystem 620 may reject the request to borrow the amount from the seconduser. If the second user authorizes the repayment terms by approving therepayment terms, the process proceeds to step 641, where the second userdevice 630 sends over the user authorization to the payment servicesystem 620 and the payment service system 620 may update the useraccounts associated with the first user device 610 and the second userdevice 630 to include the transaction with the repayment terms. This mayinclude establishing a repayment schedule with a determined feeassociated with the transaction and an interest rate charged to anyleftover amount if the first user is delinquent on paying off the debt.The process further enables significant new interactions because thefirst user device, second user device, and the payment service system asdescribed throughout.

FIGS. 7A-7C illustrate example user interfaces for a process 700 and aprocess 700 of generating payment terms associated with using a paymentcard. Similar interfaces with minor modifications may also be used toallow a user to pay off debt using the example mobile application. InFIG. 7A, a user may use a payment card 704 at a POS device 702 of amerchant for a transaction. The POS device 702 may previously have thetransaction details and wait for payment from the user. The mobileapplication 708 may provide functionalities for a user to access andmanage debt instruments. The debt instruments may include credit cards,a line of credit, or loans. As illustrated by FIG. 7B, suchfunctionalities may be provided in the user interface 710 of a mobileapplication 708 executing on a user device 706. The user interface 710may represent a screen that appears in response to the user using thepayment card 704 to pay for a transaction. The user interface 710 may bean overlay on top of another user interface that represents a homescreen of the mobile application 708. In other embodiments, the userinterface 710 may open a separate screen different from the home screen.The payment service system may determine a repayment plan that willprevent the user from being charged an interest rate for thetransaction. In particular embodiments, the payment service system maydetermine multiple repayment schedules 712 that may work best for theuser based on the transaction history, income, and cash flow of theuser. The user interface 710 may comprise a suggested repayment schedule712 a among other repayment schedules 712, such as repayment schedule712 b, and a “Confirm” button 714 directing the user to an interfaceconfirming a payment using the payment card. As shown in FIG. 7B, theuser may select the “Confirm” button 714 through a user input 716. Inparticular embodiments, a first repayment schedule 712 a may be selectedand may be differentiated from other repayment schedules 712. As anexample and not by way of limitation, the first repayment schedule 712 amay be highlighted indicating the currently selected repayment schedule712 a. In particular embodiments, there may be a plurality of repaymentschedules 712 that the user may scroll through to select the desiredrepayment schedule 712.

The user interface 718 shown in FIG. 7C illustrates the result of theuser selecting the “Confirm” button 7B through the user input 716. Inother embodiments, the application 708 may also display a confirmationpage that comprises the details of the request to access the line ofcredit in a summary format after the user selects the “Confirm” button714. The user interface 718 may comprise a confirmation date of thefirst payment 720 and a “Done” button 722 directing the user back to ahome screen, which would show an updated transaction history includingthe recent transaction.

FIGS. 8A-8E illustrate example user interfaces for a process 800 ofaccessing a line of credit using an example mobile application 802associated with a payment service system, the mobile applicationexecuting on a user device 801. Similar interfaces with minormodifications may also be used to allow a user to pay off debt using theexample mobile application 802 (e.g., substituting graphics relating toaccessing a line of credit with graphics relating to paying off debtassociated with a line of credit). The mobile application 802 mayprovide functionalities for a user to access and manage debtinstruments. The debt instruments may include credit cards, a line ofcredit, or loans. As illustrated by FIG. 8A, such functionalities may beprovided in the user interface 803. The user interface 803 may representa home screen of the mobile application 802. The user interface 803 maycomprise a balance 804 (e.g., $325) associated with the user accountdisplaying the amount of funds currently available, an “Add Cash” button805 directing the user to an interface for adding additional funds tothe balance 804, a “Cash Out” button 806 directing the user to aninterface for withdrawing funds from the balance 804. The user interface803 may comprise a “Cash” button 808 directing the user to an interfacefor managing one or more fiat currencies and one or more financialaccounts and a “Line of Credit” button 810 directing the user to aninterface for accessing a line of credit associated with the useraccount. As shown in FIG. 8A, the user may select the “Line of Credit”button 810 through a user input 812.

The user interface 814 shown in FIG. 8B illustrates the result of theuser selecting the “Line of Credit” button 810 through the user input812. The user interface 814 may comprise an available line of creditamount 816, an indication 818 of how much is borrowed from the line ofcredit, a “Borrow Now” button 820 directing the user to an interface forselecting a portion of the line of credit to access now, a “Later”button 822 directing the user to an interface for selecting a portion ofthe line of credit to access at a later date, and a details section 824providing details associated with the line of credit of the useraccount. As shown in FIG. 8B, the user may select the “Borrow Now”button 820 through a user input 826.

The user interface 828 shown in FIG. 8C illustrates the result of theuser selecting the “Borrow Now” button 820 through the user input 826.The user interface 828 may be an overlay on top of the user interface814. In other embodiments, the user interface 828 may open a separatescreen different from user interface 814. The user interface 828 maycomprise an amount 830 indicative of portion of the line of credit theuser wishes to borrow, a slider element 832 with a button 834 toindicate what portion of the line of credit the user wishes to borrow,and a “Next” button 836 directing the user to an interface fordetermining a repayment schedule for the transaction. In particularembodiments, the payment service system 108 may receive an indication ofa transaction and automatically determine an amount 830 the user maywish to borrow. The indication may be received in response to a requestto charge a payment card for a transaction or as a result of atransaction, which would bypass FIGS. 8A and 8B. As shown in FIG. 8C,the user may select the “Next” button 836 through a user input 838.

The user interface 840 shown in FIG. 8D illustrates the result of theuser selecting the “Next” button 836 through the user input 838. Theuser interface 840 may be an overlay on top of the user interface 814.In other embodiments, the user interface 840 may open a separate screendifferent from user interface 814. The payment service system 108 maydetermine a repayment plan that will prevent the user from being chargedan interest rate for the transaction. In particular embodiments, thepayment service system 108 may determine multiple repayment schedulesthat may work best for the user based on the transaction history,income, and cash flow of the user. The user interface 840 may comprise asuggested repayment schedule 842 a among other repayment schedules 842,such as repayment schedule 842 b, and a “Confirm” button 844 directingthe user to an interface confirming a request to transfer funds from theline of credit to the user's balance. As shown in FIG. 8D, the user mayselect the “Confirm” button 844 through a user input 846. In particularembodiments, a first repayment schedule 842 a may be selected and may bedifferentiated from other repayment schedules 842. As an example and notby way of limitation, the first repayment schedule 842 a may behighlighted indicating the currently selected repayment schedule 842 a.In particular embodiments, there may be a plurality of repaymentschedules 842 that the user may scroll through to select the desiredrepayment schedule 842.

The user interface 848 shown in FIG. 8E illustrates the result of theuser selecting the “Confirm” button 844 through the user input 846. Inother embodiments, the application 802 may also display a confirmationpage that comprises the details of the request to access the line ofcredit in a summary format after the user selects the “Confirm” button844. The user interface 848 may comprise a confirmation date of thefirst payment 850 and a “Done” button 852 directing the user back touser interface 803, which would show the updated balance 804 includingthe transfer from the line of credit to the balance 804.

FIGS. 9A-9F illustrate example user interfaces for a process 900 ofrequesting to borrow funds from another user using an example mobileapplication 904 executing on a user device 902, the mobile application904 being associated with a payment service system. Similar interfaceswith minor modifications may also be used to allow a user to pay offdebt using the example mobile application 904. The mobile application904 may provide functionalities for a user to access and manage debtinstruments. The debt instruments may include credit cards, a line ofcredit, or loans. As illustrated by FIG. 9A, such functionalities may beprovided in the user interface 905. The user interface 905 may representa home screen of the mobile application 904. In particular embodiments,the user interface 905 may represent a user interface after selecting anoption to borrow from friends from a home screen of the mobileapplication 904. In particular embodiments, the payment service systemmay identify suggested users that the user may wish to request to borrowfrom. As an example and not by way of limitation, the payment servicesystem may determine suggested users based on interactions between theuser and other users. For instance, if the user has sent and requestedmoney from a particular user frequently, then that particular user maybe added to a suggested user list. The user interface 905 may comprise alist of users that the user is friends with or have previouslytransacted with. The list of users comprises one of more buttons 906a-906 d that correspond to a particular user account of the paymentservice system. Each of the buttons 906 may direct the user to aninterface for requesting to borrow an amount from the respective user.As shown in FIG. 9A, the user may select the “Dennis Mills” button 906 bthrough a user input 908.

The user interface 910 shown in FIG. 9B illustrates the result of theuser selecting the “Dennis Mills” button 906 b through the user input908. The user interface 910 may comprise may be an overlay on top of theuser interface 905. In other embodiments, the user interface 910 mayopen a separate screen different from user interface 905. The userinterface 910 may comprise an amount 912 indicative of portion of theamount the user wishes to borrow, a slider element 914 with a button 916to indicate what amount the user wishes to borrow, and a “Next” button918 directing the user to an interface for determining a repaymentschedule for the transaction. In particular embodiments, the paymentservice system may receive an indication of a transaction andautomatically determine an amount 912 the user may wish to borrow. Theindication may be received in response to a request to charge a paymentcard for a transaction or as a result of a transaction, which wouldbypass FIG. 9A. In particular embodiments, the amount the user wishes toborrow may be included in the user interface 905 shown in FIG. 9A. As anexample and not by way of limitation, the user can input the amount onthe user interface 905 prior to selecting a user to borrow from. Asshown in FIG. 9B, the user may select the “Next” button 918 through auser input 920.

The user interface 922 shown in FIG. 9C illustrates the result of theuser selecting the “Next” button 918 through the user input 920. Theuser interface 922 may be an overlay on top of the user interface 905.In other embodiments, the user interface 922 may open a separate screendifferent from user interface 905. The payment service system maydetermine a repayment plan that will prevent the user from being chargedan interest rate for the transaction. In particular embodiments, thepayment service system may determine multiple repayment schedules thatmay work best for the user based on the transaction history, income, andcash flow of the user. The user interface 922 may comprise a suggestedrepayment schedule 924 a among other repayment schedules 924, such asrepayment schedule 924 b, and a “Confirm” button 926 directing the userto an interface confirming a request to transfer funds from the line ofcredit to the user's balance. As shown in FIG. 9C, the user may selectthe “Confirm” button 926 through a user input 928. In particularembodiments, a first repayment schedule 924 a may be selected and may bedifferentiated from other repayment schedules 924. As an example and notby way of limitation, the first repayment schedule 924 a may behighlighted indicating the currently selected repayment schedule 924 a.In particular embodiments, there may be a plurality of repaymentschedules 924 that the user may scroll through to select the desiredrepayment schedule 924.

The user interface 930 shown in FIG. 9D illustrates the result of theuser selecting the “Confirm” button 926 through the user input 928. Inother embodiments, the application 904 may also display a confirmationpage that comprises the details of the request to access the line ofcredit in a summary format after the user selects the “Confirm” button926. The user interface 930 may comprise a confirmation date of thefirst payment 932 and a “Done” button 934 directing the user back touser interface associated with the home screen, which would show theupdated balance of the user account including the transfer from theborrowed amount to the user balance.

The user interface 936 shown in FIG. 9E illustrates an example reminderthe user may receive at a later date to repay the borrowed money fromthe lender. In particular embodiments, the user may set up reminderswhile requesting to borrow the money from the lender. The user mayselect a frequency and/or when to receive a reminder in the future topay back the borrowed amount. As an example and not by way oflimitation, the user may select to be reminded three days before ascheduled repayment date and be reminded every day until the user paysthe amount due for the scheduled repayment date. So if the user has ascheduled repayment date on Friday, the user may be reminded on Tuesdayto pay off the amount due for that week. The user interface 936 maycomprise the reminder 938. The user interface 936 may be a home screenof a user device 902. In other embodiments, the reminder 938 may bedisplayed as a notification in other user interfaces of the user device.As an example and not by way of limitation, the reminder 938 may be apop-up notification while the user is interfacing the user device 902.As shown in FIG. 9E, the user may select the reminder 938 through a userinput 940.

The user interface shown in FIG. 9F illustrates the result of the userselecting the reminder 938 through the user input 940. In particularembodiments, the selection of the reminder 938 may open the mobileapplication 904 to a user interface 942. The user interface 942 maydisplay the recent activity of the user within the mobile application904, such as recent transactions, completed transactions, pendingtransactions, upcoming transactions, and the like. In particularembodiments, the user interface 942 may comprise upcoming transactions944 and list them for the user. Based on one or more account recordsassociated with the user stored in a database of the payment servicesystem, the payment service system may determine if an action needs tobe completed with respect to the upcoming transaction 944 and mayprovide instructions to the user device 902 to generate an interactivebutton 946 on the mobile application 904 to complete the action. As anexample and not by way of limitation, the upcoming transaction 944 maybe a repayment due and a “Repay” button 946 may be linked to theupcoming transaction 944 to allow the user to access a user interface torepay the transaction. The “Repay” button 946 may direct the user to aninterface to simply pay the next payment (e.g., amount due for the week)and/or modify to pay more of the borrowed amount. The user interface 942may comprise interactive buttons for each completed transaction 948,such as completed transaction 948 a directing the user to an interfacedetailing the transaction and completed transaction 948 b directing theuser to an interface detailing the transaction.

FIGS. 10A-10C illustrate example user interfaces for a process 1000 ofapproving a request to borrow funds from another user using an examplemobile application 1004 executing on a user device 1002, the mobileapplication 1004 being associated with a payment service system. Similarinterfaces with minor modifications may also be used to allow a user topay off debt using the example mobile application 1004. The mobileapplication 1004 may provide functionalities for a user to access andmanage debt instruments. The debt instruments may include credit cards,a line of credit, or loans. As illustrated by FIG. 10A, suchfunctionalities may be provided in the user interface 1006. The userinterface 1006 may represent an activities screen of the mobileapplication 1004. The user interface 1006 may display recent activity ofthe user within the mobile application 1004, such as recenttransactions, completed transactions, pending transactions, upcomingtransactions, and the like. The user interface 1006 may comprise pendingtransactions 1008 and list them for the user. The payment service systemmay determine if an action needs to be completed with respect to thepending transaction 1008 and may provide instructions to the user device1002 to generate an interactive button 1010 on the mobile application1004 to complete the action. The payment service system may use one ormore account records associated with the user stored in a database ofthe payment service system to make the determination if an action needsto be completed. As an example and not by way of limitation, the pendingtransaction 1008 may be a request to borrow money from another user anda “Lend” button 1010 may be linked to the pending transaction 1008 toallow the user to access a user interface to approve the transaction.The “Lend” button 1010 may direct the user to an interface to approve arequest to borrow money and/or modify one or more repayment terms forthe request to borrow money. As an example and not by way of limitation,if a user wishes to borrow money from the user associated with the userdevice 1002, then the user would receive the request under the user'spending transactions 1008 with details of the request. The userinterface 1006 may comprise interactive buttons for each completedtransaction 1012, such as completed transaction 1012 a directing theuser to an interface detailing the transaction and completed transaction1012 b directing the user to an interface detailing the transaction. Asshown in FIG. 10A, the user may select the “Lend” button 1010 through auser input 1014. In accordance with one embodiment, upon the lendinguser approving the request to borrow funds (i.e., by selecting the“Lend” button 1010), the payment service stores a record of thetransaction as between financial accounts of the requesting user and thelending user. Additionally, the payment service may generate remindernotifications associated with terms (e.g., due date, payment amount) ofthe request to borrow, and facilitate transaction processing ofrepayment amounts between the financial accounts of the two partiesbased on the repayment terms (e.g., withholding a percentage of futureincoming payments for loan repayment, automated installment amountsprocessed on due date, user interacting with “Repay” button of FIG. 9F,etc.).

The user interface 1006 shown in FIG. 10B, illustrates the result of theuser selecting the “Lend” button 1010 through a user input 1014. Theuser interface 1006 may refresh to update the activities screen tochange the pending transaction 1008 to a completed transaction 1012. Thecompleted transactions 1012 may be reordered to have the latestcompleted transaction 1012 listed first. As shown in FIG. 10B, the usermay select the completed transaction 1012 a through a user input 1016.

The user interface 1018 shown in FIG. 10C, illustrates the result of theuser selecting the completed transaction 1012 a through user input 1016.The user interface 1018 may comprise details of the completedtransaction 1012 a and an overlay 1020 that includes the details of thecompleted transaction 1012 a. The overlay 1020 may also comprise a“Forgive” button 1022 directing the user to an interface to forgive theremainder of the balance on the loan and a “Support” button 1024directing the user to an interface to contact support of the mobileapplication 1004. In particular embodiments, the “Forgive” button 1022may remove the loan from the borrower's upcoming transactions and markthe transaction as completed and forgiven.

Herein, “or” is inclusive and not exclusive, unless expressly indicatedotherwise or indicated otherwise by context. Therefore, herein, “A or B”means “A, B, or both,” unless expressly indicated otherwise or indicatedotherwise by context. Moreover, “and” is both joint and several, unlessexpressly indicated otherwise or indicated otherwise by context.Therefore, herein, “A and B” means “A and B, jointly or severally,”unless expressly indicated otherwise or indicated otherwise by context.

The scope of this disclosure encompasses all changes, substitutions,variations, alterations, and modifications to the example embodimentsdescribed or illustrated herein that a person having ordinary skill inthe art would comprehend. The scope of this disclosure is not limited tothe example embodiments described or illustrated herein. Moreover,although this disclosure describes and illustrates respectiveembodiments herein as including particular components, elements,feature, functions, operations, or steps, any of these embodiments mayinclude any combination or permutation of any of the components,elements, features, functions, operations, or steps described orillustrated anywhere herein that a person having ordinary skill in theart would comprehend. Furthermore, reference in the appended claims toan apparatus or system or a component of an apparatus or system beingadapted to, arranged to, capable of, configured to, enabled to, operableto, or operative to perform a particular function encompasses thatapparatus, system, component, whether or not it or that particularfunction is activated, turned on, or unlocked, as long as thatapparatus, system, or component is so adapted, arranged, capable,configured, enabled, operable, or operative. Additionally, although thisdisclosure describes or illustrates particular embodiments as providingparticular advantages, particular embodiments may provide none, some, orall of these advantages.

1. A method comprising, by one or more computing devices associated witha payment service system (PSS): creating, by the PSS, a user accountassociated with a user and maintained by the PSS, wherein the useraccount is associated with a payment card, the payment card having acorresponding limit and a base interest rate, wherein the user accountis further configured to record a different additional interest rate foreach of a plurality of transactions up to the limit; receiving, by thePSS, a payment request to charge the payment card for a value of atransaction; in response to receiving the payment request, identifying,by the PSS, purchase characteristics of the transaction; based on theidentified purchase characteristics of the transaction and historicalrepayment data stored in a data store of the PSS, determining, by thePSS, an additional interest rate to be associated with the value of thetransaction; providing, by the PSS after receiving the payment requestfor the transaction, the additional interest rate to be associated withthe value of the transaction to the user for approval; and uponreceiving a payment confirmation and approval of the additional interestrate from the user associated with the user account, updating, by thePSS, the user account to include the value of the transaction as anamount owed against the payment card at the determined additionalinterest rate.
 2. The method of claim 1, wherein the one or moreidentified purchase characteristics comprise one or more of: whether thetransaction is for a product or a service, a category associated withthe product or the service, a date and time associated with thetransaction, a merchant category code (MCC) associated with thetransaction, and whether the product or the service is identified as aluxury item.
 3. The method of claim 1, further comprising: facilitatingprocessing of the payment request using the user account and the paymentcard.
 4. The method of claim 1, further comprising: assessing one ormore prior transactions with a machine learning model to identify one ormore risk factors associated with the one or more prior transactions;and analyzing, by using the machine learning model, details of thetransaction to identify one or more current risk factors associated withthe transaction based on a comparison of details of the transaction tothe one or more prior transactions, and wherein determining theadditional interest rate to be associated with the value of thetransaction is further based on the identified current risk factorsassociated with the transaction.
 5. A method comprising, by one or morecomputing devices associated with a payment service system (PSS):creating, by the PSS, a user account associated with a user andmaintained by the PSS, wherein the user account is associated with adebt instrument, the debt instrument having a corresponding limit and abase interest rate, wherein the user account is further configured torecord a different additional interest rate for each of a plurality oftransactions up to the limit; receiving, by the PSS and from a mobiledevice of the user, a payment request to access the debt instrument fora value of a transaction; in response to receiving the payment request,identifying, by the PSS, characteristics of the transaction; based onthe identified characteristics of the transaction, determining, by thePSS, an additional interest rate to be associated with the value of thetransaction; providing, by the PSS after receiving the payment request,the additional interest rate to the user for approval; and uponreceiving a payment confirmation and approval of the additional interestrate from the user, updating, by the PSS, the user account to includethe value of the transaction as an amount owed against the debtinstrument at the determined additional interest rate.
 6. The method ofclaim 5, wherein the user account is a revolving account that includesdynamic repayment terms for each transaction.
 7. The method of claim 5,wherein determining the additional interest rate includes modifying thebase interest rate to a revised interest rate for the transaction. 8.The method of claim 5, wherein the debt instrument is a payment card,and wherein the payment request is a payment request to charge thepayment card for the value of the transaction.
 9. The method of claim 5,further comprising: facilitating processing of the payment request usingthe user account and the debt instrument.
 10. The method of claim 5,wherein the user is a merchant using payment services of the PSS. 11.The method of claim 10, wherein determining the additional interest ratefurther comprises using a machine learning model applied to one or moreof attributes of an item or service associated with the transaction, acurrent merchant inventory of the merchant, or a recent transactionactivity of the merchant.
 12. The method of claim 5, wherein determiningthe additional interest rate comprises using a machine learning modelapplied to one or more of an incoming payroll, a deposits activity, cashflow associated with equities or securities, or peer-to-peertransactions.
 13. A payment service system (PSS) comprising: one or moreprocessors; and one or more computer-readable non-transitory storagemedia coupled to one or more of the processors and comprisinginstructions operable when executed by one or more of the processors tocause the payment service system to: create, by the PSS, a user accountassociated with a user and maintained by the PSS, wherein the useraccount is associated with a debt instrument, the debt instrument havinga corresponding limit and a base interest rate, wherein the user accountis further configured to record a different additional interest for eachof a plurality of transactions up to the limit; receive, by the PSS andfrom a mobile device of the user, a payment request to access the debtinstrument for a value of a transaction; in response to receiving thepayment request, identify, by the PSS, characteristics of thetransaction; based on the identified characteristics of the transaction,determine, by the PSS, an additional interest rate to be associated withthe value of the transaction; provide, by the PSS after receiving thepayment request, the additional interest rate to the user for approval;and upon receiving a payment confirmation and approval of the additionalinterest rate from the user, update, by the PSS, the user account toinclude the value of the transaction as an amount owed against the debtinstrument at the determined additional interest rate.
 14. The paymentservice system of claim 13, wherein the user account is a revolvingaccount that includes dynamic repayment terms for each transaction. 15.The payment service system of claim 13, wherein determining theadditional interest rate includes modifying the base interest rate to arevised interest rate for the transaction.
 16. (canceled)
 17. Thepayment service system of claim 13, wherein the instructions are furtheroperable when executed by the one or more processors to cause thepayment service system to facilitate processing of the payment requestusing the user account and the debt instrument.
 18. The payment servicesystem of claim 13, wherein the user is a merchant using paymentservices of the PSS.
 19. The payment service system of claim 18, whereindetermining the additional interest rate further comprises anapplication of a machine learning model to one or more of attributes ofan item or service associated with the transaction, a current merchantinventory of the merchant, or a recent transaction activity of themerchant.
 20. The payment service system of claim 13, whereindetermining the additional interest rate comprises an application of amachine learning model to one or more of an incoming payroll, a depositsactivity, cash flow associated with equities or securities, orpeer-to-peer transactions.
 21. The method of claim 4, furthercomprising: upon receiving a payment confirmation from the userassociated with the user account and approval of the additional interestrate, storing the identified purchase characteristics in associationwith the additional interest rate for use in future training of themachine learning model.